Date: Sun, 12 Dec 93 04:30:28 PST 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V93 #144 

To: Ham-Digital 


Ham-Digital Digest Sun, 12 Dec 93 Volume 93 : Issue 144 


Today's Topics: 
9k6 baud packet - is there any point? 
COMPLETE Documented NOS Wanted 
Modifying the 16550 chips on the RS-232 cards 
Need advice on using tube-final rigs for RTTY/AFSK 
Q: G3RUH 9600 and Kenwood TM721 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Thu, 9 Dec 1993 07:15:38 +0000 

From: pacbell.com!sgiblab!swrinde!cs.utexas.edu! howland.reston.ans.net!pipex! 
uknet! demon! llondel.demon.co.uk!dave@network.ucsd.edu 

Subject: 9k6 baud packet - is there any point? 

To: ham-digital@ucsd.edu 


In article <FROUD.93Dec8202731@sunlab41.sx.ac.uk> froud@sunlab41.sx.ac.uk (How 
much wood could a woodchuck chuck if a woodchuck could chuck wood?) writes: 
>Just a minor point I wouldn't mind cleared up if anyone has a few seconds... 
> 

>I read that rigs had to be modified to allow upwards of 2k4 baud transmission, 
>but is this pointless if the person you are trying to commmunicate with 
>hasn't a repicrocal modification at the either end to allow reception of 
>higher baud transmissions? 

> 

Unlike land-line modems, there is no speed negotiation on packet (unless you 
are using strange kit) so you have to set up your rig/TNC to work at a 
particular speed. Once you have tried 9600baud you will think that 1200 is 


xveryx Slow. It isn't hard to modify rigs either.... 


Dave 
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* G4WRW @ GB7WRW.#41.GBR.EU AX25 * Start at the beginning. Go on * 
* dave@llondel.demon.co.uk Internet x until the end. Then stop. * 
*x g4wrw@g4wrw.ampr.org Amprnet x (the king to the white rabbit) x 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Date: 10 Dec 1993 12:41:00 GMT 

From: ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net!pipex!uknet! warwick! 
unicorn.nott.ac.uk!unicorn.nott.ac.uk!eeyimkn@network.ucsd.edu 

Subject: COMPLETE Documented NOS Wanted 

To: ham-digital@ucsd.edu 


Hi folks, 

You might like to know that I'm currently working on a (relatively brief) guide 
to getting up and running with NOS, provisionally entitled 'NOS for Dummies’. 
This may change :-) 


It won't cover nearly as much in depth as Ian's book, but should be able to help 
with the basics of starting up. It'll be freely available as TeX source or 
Postscript. I started it earlier this year as a mini-project, but it's grown out 
of all proportion, so I'll probably finish it some time next spring, depending on 
whether I include the stuff about running IP through Linux or not, and on how 
long it takes for me to finish porting the existing text from Micro$oft Word to 
Tex.. 


73 Mike G7GPA 


+- Mike Knell, University of Nottingham, UK -=- M.Knell@unicorn.nott.ac.uk --+ 
| --THIS SPACE TEMPORARILY BLANK-- | AMPR: g7gpa@hobbes.g7gpa.ampr.org | 
| (until I can think of a decent joke)| AX25: g7gpa@g7gpa.gb7bad.#23.gbr.eu_ | 
|UNDER the overpass! OVER the underpass! Around the future and BEYOND REPAIR! | 


Date: Thu, 9 Dec 1993 19:18:51 GMT 

From: das.wang.com!wang! garyf@uunet.uu.net 

Subject: Modifying the 16550 chips on the RS-232 cards 
To: ham-digital@ucsd.edu 


postmaster@asarin.ORG.AR writes: 


>Notes on a modification to PC's using the INS16550A UART IC for reception of 
>9600bps data from the U0O-22 satellite. These form the basis of an article to 
>be published in Amsat-UK's journal OSCAR NEWS to whom permission to copy this 
>article, and the accompanying diagram, for publication should be sought. 


>Background 


>Most PC's use the 16450 UART IC for serial communications (also equivalent to 
>the INS8250A and CMOS versions of both). With the advent of 9600bps satellite 
>communications some folks, especially with slower PS's, noticed that they got 
>errors on the TNC-to-PC link; this shouldn't happen ! The finger of suspicion 
>pointed to the software making disk accesses and missing receive data whilst 
>doing so. The 16550A UART (and CMOS 82C550A) is functionally equivalent to the 
>16450 but has an internal FIFO store holding 16 bytes of data and someone put 
>the thought forward to try it. It certainly cleared up problems for some folks 
>but others had a change of symptom; PB would just stop receiving even though 
>data was coming from the TNC to the PC. After much research and international 
>co-operation I think we have a hardware solution to these problems. 


>The solution supposes that the reason for the apparent freezing of PB is due 
>to the fact that the 16550A interrupt line goes high to assert and stays high 
>until the interrupt is serviced. (The more common 16450 IC also does this; I 
>don't know why PC's don't freeze with it.) If the PC is serving another 
>interrupt at the time the 16550A asserts then the new one doesn't get to be 
>seen ... hence no receive data. I have actually seen this happen on an 
>oscilloscope and the interrupt line was stuck high at the time of the freeze. 


Your observation is correct, but there is a simple software solution to the 
problem. The basic problem is that the IBM PC uses edge triggered interrupts 
instead of level triggered ones (I'd like to strangle the guy at IBM who 
made that decision). A properly written COM port driver should clear the 
interrupt as early in the interrupt handler as possible and then just before 
re-enabling interrupts and exiting it should check whether any additional 
characters are available and if there are, read those too. 


>The earlier belief that the FIFO needs to be switched ON is not correct, the 


PAV AY AT AVAYAVAVAYAVAVALAVAVATATAVATATATAVATATAVATATATATATATATATAVATATATATATAVATATAVATATATATATATATATATATATATATATATATATATATALATATATATATATATAVATAS 


Yes it is! The FIFO does NOT default to being used. The COM port driver (BIOS) 
needs to be 16550 aware and enable the FIFO. The reason it doesn't default to 
ON is that software that is not aware of the FIFO would get confused by it. 


>FIFO in the 16550A is operative all the time; the software issued some time 
>ago merely sets different TRIGGER levels for the UART's "data available" flag. 


It looks like you did a lot of work on this, but I think you got carried 
away with a hardware fix for a software problem. 


Gary 
--/x Gary A. Field - WA1GRC, Wang Labs M/S 019-72B, 1 Industrial Ave 
Lowell, MA 01851-5161, (508) 967-2514, email: garyf@wiis.wang.com, EST5EDT 
A waist is a terrible thing to mind! */ 


Date: Wed, 8 Dec 1993 14:19:15 GMT 

From: olivea!sgigate.sgi.com!sgiblab!swrinde!emory!kd4nc!ke4zv! gary@decwrl.dec.com 
Subject: Need advice on using tube-final rigs for RTTY/AFSK 

To: ham-digital@ucsd.edu 


In article <2e1o05h$n77@klaava.Helsinki.FI> stickler@klaava.Helsinki.FI (Patric M 
Stickler) writes: 

>I'll be shopping for a used rig soon and will be on a very tight 
>budget, so I'm trying to get a picture of what the minimal rig would be 
>that will do what I want. Other than SSB/CW, I've been itching to get 
>into RTTY, but have heard that many older rigs have problems both from 
>the 100% duty cycle and sluggish operation. 

> 

>I'm intrested in hearing people's experiences working the various 
>digital modes on HF using older tube rigs, or rigs with tube finals. 
>More than likely, I'll be using a late-model multimode TNC and AFSK for 
>HF RTTY/Baudot/AMTOR. What sort of things should I look for ina 
>suitable rig. Obviously, the quality of the SSB signal is more 
>important when using AFSK rather than FSK (right?). How can one 
>estimate the max. drive the finals can take at 100% duty cycle? How 
>can one determine if the tx is "fast" enough (or is sluggishness 

>only a problem with FSK and not AFSK?). 


Ok, I use two different rigs for the HF digital modes. I use the 

IC735 and a B&W6100 and Drake RAC. The former is, of course, a 

modern solid state transceiver. It performs well on all the digital 
modes. It has IF shift that allows the narrow filter to be positioned 
correctly for the digital tones even in SSB mode. It will allow either 
AFSK or FSK transmission. FSK is generally preferred. It switches 
quickly enough for AMTOR. For RTTY, drive should be reduced to 50 
watts output. For AMTOR and packet, full power is OK since it has 

an excellent thermal design. 


The B&W6100 uses a pair of 6146Bs in the final and is rated at 

180 watts PEP in SSB mode. It too needs to be throttled back to 

50 watts for RTTY, and can handle about 120 watts AMTOR or packet. 

When I used the Drake T4X, it was necessary to throttle back the 

sweep tube finals to about 20 watts for RTTY because their dissipation 

is insufficient for higher power steady carrier use. In general, use 

the manufacturer's recomendation for AM voice power level for RTTY. 

If you don't have the manual, divide normal xaveragex SSB power levels 

by 2 for real transmitting tubes, and by 4 for sweep tubes. Average 

power under SSB is very difficult to characterize because it's fundamentally 
tied to voice characteristics. A good rule of thumb is that it's 20% of 

the *input*x PEP rating. AMTOR and packet, because they transmit intermittantly, 
can use somewhat higher power levels. 


Radios that use open frame TR relays can be a problem for AMTOR, but 
not always. Often it is the AF stage recovery time that dominates 

the TR turnaround. Open frame relays can be fast enough, and vacuum 
relays always are fast enough. In rigs that switch the B+ to the 
receiver, you may need to change the value of power supply decoupling 
Capacitors in order to get a short enough time constant for receiver 
recovery. Or, you can modify the TR switching so that B+ stays hot 
and mute the receiver another way. That's the method I normally use. 


Don't be concerned about the apparent low power levels on RTTY. It 
doesn't take a lot of power to get good print at intercontinental 
distances providing the other station has a good TU, not a PK232 

or KAM. Something like an ST-6 does wonders for digging out signals 
that are below the noise to the ear. The PK232 will allow you to 
put an external modem ahead of it, so using a ST-6 with it is an 
option. I don't think the KAM will support that without modifications. 
And of course for RTTY all you need is the ST-6 and a modem program 
that supports Baudot running on your computer, or an honest to God 
old mechanical teletype. The ST-6 will also work with some of the 
packet programs that do the bit banging in software. I don't know 
of any software only AMTOR programs so you're stuck with using the 
PK-232 as the protocol engine in that case. Some of the newer DSP 
boxes may be as good, or better, than the ST-6, but I haven't done 
a side by side test yet. 


Gary 
Gary Coffman KE4ZV | I kill you, | gatech!wa4mei! ke4zv! gary 
Destructive Testing Systems | You kill me, | uunet!rsiatl! ke4zv! gary 
534 Shannon Way | We're the Manson Family | emory!kd4nc!ke4zv! gary 

| 


Lawrenceville, GA 30244 | -sorry Barney 


Date: 8 Dec 93 11:30:53 GMT 

From: metro! basser.cs.su.oz.au!harbinger.cc.monash.edu.au! yeshua.marcam.com! 
news.kei.com!ddswi1! library.ucla.edu!news.mic.ucla.edu!ctc.com!pitt.edu!gatech! 
howland.reston.ans.@munnari.oz.au 

Subject: Q: G3RUH 9600 and Kenwood 1TM721 

To: ham-digital@ucsd.edu 


I am looking for info about connecting 9600 modem type G3RUH to a Kenwood TM721A. 
Thanks in advance, 
4X1BQ, Yossi Sharon 


Internet: yosi@eng.tau.ac.il 
Packet: AX1BQ@4X1RU.isr.mdle 


Date: 11 Dec 1993 01:29:21 -0800 
From: ukma!nntp.msstate.edu!olivea!apple.com!apple.com!not-for-mail@seismo.css.gov 
To: ham-digital@ucsd.edu 


References <1993Dec6.174733.27968@mixcom.mixcom.com>, <2e3vpa$dg9@spock.usc.edu>, 
<jschulma.21.Q00F2EAC@uiuc.edu>du 
Subject : Re: When will we get digital cellular? 


In article <jschulma.21.000F2EAC@uiuc.edu>, 

Jay S. Schulman <jschulma@uiuc.edu> wrote: 

>Speaking as someone who has been testing digital for a few months for 
>Motorolla, it is not what it is cracked up to be. Don't get me wrong, ina 
>few years digital cellular will be what analog is today. But, right now, 
>digital sounds terrible! It sounds like you are talking into a cheap computer 
>and listening to the playback. Besides heavy hissing and other background 
>noice, your voice alone makes it difficult for others to understand you. 


Sounds like TDMA cellular is really awful at this point! I tried a 
CDMA phone during a test one day and the audio quality was just fine-- 
even with 50 or 60 other people using the same channel at the same time. 


>To anyone considering digital: 
> 
> Wait. It will get much better in the future. 


I guess how far in the future you'll have to wait for decent 
quality depends on which type of digital cellular is being 
installed in your area. :-) 


SS Patty Winter a 
Apple contractor Internet: winter@apple.com 
Sunnyvale, California AMPRNet: 44.4.4.50 


"What about truth? What about reality?" 
"What about the way the old ending tested in Canoga Park?" 


SS N6BIS SS 


End of Ham-Digital Digest V93 #144 
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